Über den Software-Qualitätsbegriff - Teil 2: Anforderungen und Merkmale am Beispiel Solftware-Ergonomie (Usability)

Dieser Beitrag führt die Diskussion um den Begriff Software-Qualität fort [Petr99b]. Ausgangspunkt war die Feststellung, dass es nicht genügt, den Qualitätsbegriff zu definieren, um ein einheitliches Verständnis für Qualität bei den Beteiligten zu erreichen. Vielmehr sind qualitätsbestimmende Begriffe wie Forderung und Merkmal zu klären. Auch stellt sich die Frage nach der Verwendung dieser Begriffe im Rahmen von Entwicklungsprozessen und Vorgehensmodellen (vgl. [Petr99a]). In die Kritik geraten dabei Normen und Standards wie beispielsweise die ISO 9001 oder das V-Modell 97, die kaum zur Klärung beitragen. Die Problematik des Qualitätsbegriffes auch in Verbindung mit Prozessstandards sei daher nochmals kurz erläutert. Weiterhin seien einige kontroverse Argumente vorgestellt, und um das Problem mit der Software-Qualität zu veranschaulichen, ist ein Beispiel aus dem Bereich Software-Ergonomie gegeben. Allerdings kann und will dieser Beitrag keine „Küchenrezepte“ liefern, sondern hauptsächlich auf die Schwierigkeiten beim Umgang mit Qualität hinweisen und die Diskussion beleben. 1. Was ist Software-Qualität? Das Begriffspaar Forderung und Merkmal nehmen eine zentrale Stellung bei vielen Definitionen für Qualität ein, z.B. bei der ISO 8204: „Gesamtheit von Merkmalen [...] einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen“ [DIN8204]. Allerdings finden sich in der Literatur unterschiedliche Bezeichnungen für Forderung und Merkmal. So werden Forderungen oftmals auch als Anforderungen, Requirements, Needs oder Bedürfnisse bezeichnet. Merkmale finden sich in der englischsprachigen Literatur als Characteristics. Nun ist leicht einsehbar, dass sich hinter Forderungen und Merkmale außerordentlich komplexe Sachverhalte verbergen, so dass z.B. eine Strukturierung, Verfeinerung und Hierarchisierung notwendig wird, damit Anforderungen operationalisierbar und prüfbar werden, denn Requirements wie Aufgabenangemessenheit (als Beispiel für eine ergonomische Anforderung als Teil der nicht-funktionalen Anforderungen) können kaum direkt im SoftwareEntwurf bzw. der Implementierung umgesetzt werden. Wichtig erscheint insbesondere die Prüfoder Testbarkeit: Es genügt bekanntlich nicht, von „ausreichender Antwortzeit“ zu sprechen, da diese Anforderung nicht testbar ist. Auch die Quantifizierbarkeit bei der Bewertung kann ein Problem darstellen, denn das Ergebnis einer Prüfung lautet nicht immer „erfüllt“ oder „nicht erfüllt“, d.h. das Skalenniveau ist zuweilen recht unterschiedlich. Weitere Aspekte tragen zur Komplexität bei, z.B. die externe und interne Qualität sowie die Quality in use [DIN9126], die quasi „Sichtweisen“ auf eine Software darstellen. Auch ist zwischen Prozessund Produktqualität zu unterscheiden. Zusammenfassend lässt sich feststellen, dass erst die Zuordnung von Merkmalen zu den Forderungen eine Qualitätsaussage ermöglicht. Nur wenn geklärt ist, was die Anforderungen sind und welche Merkmale einer Software Relevanz für deren Erfüllung haben, ist Software-Qualität ermittelbar. 2. Stand der Diskussion Angesichts des o.g. leicht verständlichen Konzeptes für Qualität stellt sich die Frage, was am Qualitätsbegriff bzw. an dessen Verwendung diskussionswürdig sein soll. Zwei Punkte sind hier in erster Linie zu nennen: • Obwohl mit der ISO 8204 eine Definition für Qualität vorliegt und einige Normen diese Festlegung auch übernehmen, ist dennoch eine einheitliche Verwendung weder in der Standardliteratur, noch in den einschlägigen Normen und Standards zu beobachten. Nicht einmal innerhalb der ISO scheint es eine klare und konsistente Linie zu geben: Die ISO 9126 [DIN9126] beispielsweise verwendet den Begriff Quality (Sub-)Characteristic, z.B. in Verbindung mit Usability, während die ISO 9241-10 [ISO9241] von Ergonomic Requirements spricht, welche ebenfalls die Usability betreffen. Dies ist zumindest auf der terminologischen Ebene verwirrend. • Viele Prozessnormen bzw. Vorgehensmodelle greifen das Konzept von Anforderungen und Merkmalen überhaupt nicht auf. Dies betrifft z.B. die ISO 9001 [DIN9001], die ISO 15504 [ISO15504] oder das VModell 97 [Bund97]. Es ist zwar oftmals von Anforderungen (Requirements) die Rede, aber auf Merkmale und deren Prüfung gegen die Anforderungen findet sich nichts oder kaum etwas. Dabei wäre dies zwingend notwendig – nicht nur um Prüfungen durchführen zu können, sondern beispielsweise auch für das Requirements Tracing. Die begriffliche Vielfalt wiegt sicherlich nicht so schwer, wie die mangelhafte Unterstützung durch die Prozessnormen und Vorgehensmodelle: Um die Behauptung zu stützen, dass sich eine hohe Prozessqualität auch positiv auf die Produktqualität auswirkt, wäre eine prozessorientierte und detaillierte Beschreibung notwendig, wie Anforderungen als Ausgangspunkt mit Merkmalen des Produktes zu verbinden sind, so dass sich Qualität auch auf der nicht-funktionalen Ebene (z.B. bei softwareergonomischen Anforderungen) nachweisen lässt. Bevor näher auf das Thema Software-Ergonomie eingegangen wird, seien einige Gegenargumente bzgl. der o.g. Kritikpunkte genannt, wobei zu beachten ist, dass die Autoren der Argumente nicht namentlich genannt werden, hauptsächlich aber Vertreter von Prozessnormen und Vorgehensmodelle im positiven Sinne sind: • Gegenargument #1: Einige Normen (z.B. ISO 9001) unterscheiden nicht zwischen Anforderungen und Merkmalen, weil diese Differenzierung einen zu hohen Detaillierungsgrad bewirken würde. Wenn also in den Werken von Qualität bzw. Anforderungen gesprochen wird, dann ist damit der Qualitätsdefinition ausreichend genüge getan. Eine genauere Betrachtung bzgl. Anforderungen und Merkmale ist nicht notwendig. • Gegenargument #2: Einige Standards wie das VModell 97 enthalten einige Verweise auf andere Normen, was völlig ausreichend ist. Es ist nicht das Ziel von Standards bzw. Vorgehensmodellen, genaue Angaben über die Anforderungen und Merkmale zu machen. • Gegenargument #3: Um methodenunabhängig zu sein, können Prozessnormen und Vorgehensmodelle nun einmal nicht detaillierter sein. Schließlich soll nur der Prozess, nicht das Produkt beschrieben werden. • Gegenargument #3: Es ist gar nicht möglich, zu jedem Merkmal eine Anforderung zu definieren. Im Falle von ergonomischen Merkmalen, z.B. einem CancelButton, müsste es dann zu jedem Element eine separate Anforderung geben, was nicht realistisch ist. Bei genauer Betrachtung, sind die Gegenargumente nicht schlüssig: Bei, Argument #1 stellt sich die (Gegen-)Frage, warum Qualität erst mit den beiden Begriffen Anforderungen und Merkmalen definiert wird und dann genau diese beiden Begriffe praktisch keine Rolle mehr spielen. Würde also das Argument stimmen, dann sollte auch die Qualitätsdefinition abstrakter werden, was allerdings wenig hilfreich wäre, da die Software-Entwicklung einen Bedarf nach einer möglichst konkreten Unterstützung hat. Ähnliches gilt für das Argument #2: Wieso ist ein Vorgehensmodell wie das V-Modell 97 nicht in der Lage, methodenunabhängig das Vorgehen zur Transformation von Anforderungen zu Merkmalen sowie die Prüfung von Merkmalen beschreiben? Das ist nicht nachvollziehbar. Auch das Argument #3 ist bereits durch die Realität widerlegt: Praktisch jeder Style Guide für das User Interface, der technische Anforderungen an eine Benutzungsoberfläche definiert, gilt für eine beliebige Anzahl von Dialogen und Interaktionselementen, d.h. es muss durchaus 1 Interessante Kritikpunkte bzgl. Normen finden sich auch in [Balz95]. 2 Diese Gegenargumente erreichten mich als Feedback auf den ersten Artikel „Über den Software-Qualitätsbegriff“ [Petr99b]. 3 Außerdem sind die Argumente nicht wörtlich, sondern nur sinngemäß wieder gegeben, da z. T. nur mündliche Gespräche geführt wurden. 4 Zur Erinnerung: Finden sich im Submodell SE (Systemerstellung) teilweise noch die Begriffe „Anforderung“ und „Merkmal“, kommt der Begriff „Merkmal“ im gesamten Regelungsteil des Submodells QS (Qualitätssicherung) überhaupt nicht mehr vor. nicht für jedes Merkmale eine separat definierte Anforderung existieren. Dass sich das Qualitätskonzept mit Anforderungen und Merkmalen durchaus in einer allgemeinen Vorgehensweise unterbringen lässt, zeigt das Quality Function Deployment (QFD): In einer Art Matrix, dem House of Quality, ist das WAS (Kundenanforderungen) und das WIE (Merkmale) abgebildet, wobei einerseits die Korrelation der Merkmale und andererseits der Unterstützungsgrad der Merkmale in Bezug auf die Anforderungen anzugeben sind ([Zoll02, S. 124], [DGQ], s. Bild 1).